


AMDUA _ 
Akup. News 


Bay Area Micro Decision Users Association « Bay Area Kaypro Users and Programmers , 


Lia ype + Speeders mes ae ee 





1 
: 4 
Is It Worth Repairing? . 2... 2. 2 2 ee ecw ew ew ew ee ew ew 8B 
WWols for TYLOs:. 6.6 2S SS we ee ee Se ee Se we eS ee 8 
Hints and Kinks from the BBS... . 2-22.22 eee ee ee 1 
MOR"S. Corer & <2 5. 6 6 eee: ow a oe Ss See Se ee 


January/February 1989 Vol. 2, Now. 1 





BAMDUA-BAKUP NEWS is published bimonthly by Bay Area Micro Deci- 
sion Users Assn. in cooperation with Bay Area Kaypro Users & 
Programmers, both Cal. non-profit corps., for their members. 
Mempership fee to join, renew, or extend is $20/yr-BAMDUA, $20/ 
yr-BAKUP. Both organizations founded in early 1980's to support 
users Of Morrow MD & Kaypro CP/M computers, respectively. Both 
now have many users of other systems including MS-bOS. Both 
maintain libraries of CP/M-compatible public domain software & 
24 hr. remote bulletin board systems. For information, send 
self-addressed stamped envelope to mail address. For BBS regis- 
tration see online bulletin. Since ceasing publication, Morrow 
Owners Review (MOR) provides some material for publication, & to 
fulfill outstanding subscriptions, it purchases & separately 
mails copies of each issue, also continuing its own BBS. 


USER GROUP MAIL ADDRESSES PUBLIC MEETINGS 
BAMDUA BAKUP Albany Senior Center 
P.O. Box 5152 P.O. Box 8537 846 Masonic Avenue 
Berkeley, CA 94705 Berkeley CA 94620 Albany, CA 
415-654-3882 BBS 415-849-9389 BBS 3d Tues. each month 
534-4257 voice 7:30 pm — near 
answer machine corner Solano Av. 

BAMDUA OFFICERS 
President Peter Campbell 
Treasurer Robert Dupuy 
Secretary George Borys 
Programs Rick Charnes 
News letter Ilbert Butler 
Library Gene Korte 
At Large Sypko Andreae, Georgia Babladelis, Ron Jacows, 


Wesley Jonnson 
BAKUP OFFICERS 


President Robert D. Athey, Jr. 
Treasurer Rovert Dupuy 
Secretary & Programs Dave Bortin 
News letter Frederick Winyard 
At Large Dwight Chew, James Ullrey 
BAMDUA PBBS/RCPM (& Similar MOR PBBS/RCPM) 
Phones: (415) 654-3882 BAMDUA Sysops: Steven Wartofsky 
654-3798 MOR Sypko Andreae 
Baud: 300/1200/2400 Free: BAMDUA & BAKUP 


Hardware: Morrow MD Hard Disk - CP/M 3.0 - 2 X 22 Mg 
Software: PBBS, BYE, KMD, ZFILE, LUX, MAP, also PRACSA Member 


Current Circulation: 550 


The Cantankerous Computerist by Robert D. Athey, Jr. 


"where Do I Get The Help I Need For This Electronic Idiot?" 

As you well know, I don't know much about computers. I've 
learned a few things simply because I've been around them a long 
time. I also know my limitations - know what I don't know, and 
am willing to admit it freely. So, I need help frequently - 
partly because I try something I think should be do-able and 
find I can't do it. Most of the time, I find some way to get it. 
done, and since you may run into a similar need, you might like 
my list of where I get help. 

There are two reasons for a list of this kind. First of 
all, I recently had a virus attack that soaked up RAM in my 
three MUSH.DOS computers. I had to reach the whole network for 
that one, and it's been isolated in one computer and eliminated 
on two others. The second reason to think of the list is the 
raft of BAKUP related phone calls waiting for me as_I recently 
returned from a foreign trip. Each wanted a different sort of 
help, and they soaked up the range of my references. 

When I run into a problem, I run through a list of several 
help aids that will usually give me what I need to solve the 
problem. I only run into problems of three kinds - hardware, 
software and operating system. Each calls for a similar (but 
different) list of aid givers. Now, I must admit that lots of 
times, I'll think up a way to work around a problem. That's 
simply a matter of coming at the problem from a different direc- 
tion. Using a spread sheet for a data base sort of problem, for 
instance, because I've never taught myself how to use Perfect 
Filer, File Express or dBase. Laziness calls for invention, on 
occasion. Eventually, though, I have to get a solution to the 
problem. In that instance, I pursue the solution to the problem 
aggressively. 

In each instance, my first step is to check the documenta- 
tion. If that's lucid enough for me to understand, I can solve 
the problem. BUT ... it's not common that the MS.DOS or CP/M 
operating system manuals give me that much benefit. The newer 
manuals from the software companies are really good on programs, 
and I've let that be known in my reviews. I also have a set of 
files from Computer Currents and MicroTimes for specific appli- 
cations (modems, etc.) as references. 

If the manual is no help, I then go into my library for 
books, magazines and user group newsletters. I frequently re- 
member vaguely having seen some item dealing with my problem in 
MicroCornucopia, FogHorn, Profiles or Bakup/Bamdua. Looking 
through them is entertaining, too. The books I go to are from 
the MS.DOS world, as I've been sent about a dozen or more to re- 
view for various publications. Books from Sybex, Osborne-McGraw- 
Hill or others may be in your local library. There are several 
Sybex books that reduce the complexities of MS.DOS to people 
language, and they are in varying grades of difficulty, from 
rank beginner to "power-user" (a piece of jargon I don't like). 
Some of those books are: 

1. Operating systems: The ABC's of the PC and Compatibles 
by Joan Lasselle and Carol Ramsay, Sybex (fairly elementary). 
DOS Users' Desktop Companion by Judd Robbins, Sybex (intermedi- 
ate). 
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2. Spread Sheets: Guide to Spreadsheets Using VP-Planner by 


Normar Sondak, HoldenDay (elementary to intermediate). 

3. Word Processing: WordStar Instant Reference by David 
Clark, Sybex (elementary to intermediate). 

I really don't think the power users need any listing from 
me. 

If that literature search doesn't work, I start making 
phone calls, first to my friends who are only slightly more 
techy than I am. From them I can I often get a little program to 
examine or eliminate my problem. For instance, Nancy Mulvany 
gave me a public domain program called PCMAP.COM that confirmed 
something was eating my RAM. The MS.DOS program called 
CHKDSK.COM tells you how much RAM is there, and how much is 
available, but not what's taking up the unavailable space. PCMAP 
tells you that COMMAND.COM has 30K, the disk parking program has 
2K, and lists all the "TSR" programs with their RAM need. BUT... 
if it shows you an "unknown" taking up the RAM, you may have a 
problem like mine! Since I did the back-up, clean-up by reformat 
and reload two weeks ago, the PCMAP has me showing no unknown 
RAM assignments. 

My youngest daughter, a Univ. of Pittsburgh computer room 
supervisor, sent me VIRUS GUARD, and the El] Cerrito Plaza Secur- 
ity Chief (my office is in El Cerrito Plaza) gave me FLU SHOT, 
both of which were installed two weeks ago. The former has a 
"RAM WATCH" feature which also monitors modification of the boot 
tracks. Reboots have let me know the boot tracks are still being 
modified, but FLU SHOT doesn't show any attacks.on *.exe, *.com, 
*.bat or *.sys programs -- yet. Although all the MS.DOS com- 
puters are 640K RAM, some had RAM consumption to the point that 
less than half was available in the worst cases. That meant I 
couldn't use WordStar 2000, Publish It, or some other items. 

All of those calls are absolutely unofficial - just to 
friends. For more sophisticated help, I call Ted De Castro, Stew 
Pugh or some other more techy type. The most official calls are 
to the local computer seller on a hardware problem, and the 
software purveyor on a software problem. Indeed, I've even sent 
a print-out of the problem to several software companies where 
their program screwed up. In one case, the WordStar problem 
print-out showed two problems and they only saw one which hap- 
pened to show I didn't use their documentation thoroughly. As 
soon as it was corrected, I saw the other problem immediately. 
For hardware problems, I call Roger Laurel at El Cerrito Heath- 
zenith or the Berkeley Computer people. 

A lot of problems are really dumb. I had difficulties with 
Perfect Writer and Perfect Calc once, getting them to call or 
save a file from within another file. It turned out that one 
needed to specify the disk drive along with the file name: "B: 
filename.doc" instead of "filename". The Perfect software people 
in Berkeley gave me the solution in 1983, and someone at a user 
group meeting reminded me of it in 1985 for Perfect Calc. In 
both cases, the solution was so simple I could only say “Argh, 
why didn't I think of that?" 

A good portion of the difficulty is bound up in the ever 
increasing complexity of these beasts. I still have the KayPro 
in my office hooked up to the dot matrix printer (via a switch) 
so I can bat out a quick letter on VDO, if I want it fast. It 
ee ee 
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can be doing that while the MS.DOS computer is occupied reading 
a page of text with my Saba PageReader. I never had problems 
with bad programs, viruses, Trojan horses and so on with the 
KayPro. All this is new and not pleasing since I got the "big- 
ger, faster, color, ..." computer. I think there's a message in 
that. 

In any case, when someone calls me, I quite commonly don't 
have an answer. I will refer the caller to someone else who I 
think may be able to handle it. Many are referred to the phone 
list in the back cf the BAKUP/BAMDUA Newsletter, but some are 
referred to Berkeley Computer, Silicon Valley Surplus or El 
Cerrito Heath-Zenith. Some are referred to Computer Currents or 
MicroTimes columns or classifieds, and some to the local library 
where they'll find a book or two. 

In summary, I run into trouble now and again. My approach 
to finding the solution of the problem by: 

1. Looking in the manual; 

2. Looking in other literature (books, files, magazines); 
3. Calling friends or asking the user group meeting; and, 
4. Calling the supplier of the hardware or software. 

In most cases, it works out nicely, and I can get on with 
my life of writing, playing games and doing some real work. A 
happy combination. 


"your Call Cannot Be Completed. . ." 


Yes, we really did give you the wrong number for the MOR BBS 
in the last issue. But look at it this way: we were only off 
by one little itty bitty number. All the other numbers were 
dead right. Pretty close, huh? It's not like we got all the 
numbers wrong. 

Anyway, this time we got all the numbers right, and if 
you don't believe it, give it a try. 


654-3798 


The MOR BBS (Sypko Andreae, Sysop) has invited all 
former BAKUP BBSers to join at no charge, and soon the 
BAMDUA BBS will also merge with MOR. It's the same old gang 
at. a new number. 
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FROM THE MAILBOX by Bill Steele 
eo ee ee ee 


P.O. Box 782, Ithaca, NY 14851; (607) 273-2132 . 





Gordon Northrup, who was looking for a way to access a "Rolodex" 
while in NewWord, writes, "I solved the problem by using VDE, 
which gives room for LBRDSK and a file of at least 150 ad- 
dresses." I love it when people solve their own problems! 

Dr. Northrup also asks if he could use his MP-100 and PCjr 
printers and his MDT-60 terminal with an IBM compatible com- 
puter. The printers will work, perhaps with some patching of 
software to insert the right printer codes (most software should 
have Silver Reed printers as an installation option, and that 
should work with the MP-100; see previous colunns). The terminal 
is something else again. A PC or clone generates a video signal, 
similar to the video output of a VCR, to drive the monitor; Mor- 
rows generate a digital signal that is sent through an RS-232 
cable to the terminal, which translates the digital signal into 
video for display. Our terminals don't have inputs that would 
accept the video signal from a PC, though I suppose one could be 
modified by a technician. Anyone out there have experience doing 
that? Even if you did that, our terminal keyboards don't put 
out all the codes a PC needs, and I don't think the keyboard 
cables are compatible. 

With appropriate software it's possible to operate a PC 
from a remote terminal, just as we can operate a BBS or a main- 
frame over the phone; of course the "remote" could just as well 
be in the same room, connected by a cable. Seems like the long 
way around, since monitors are cheap, and most clones come with 
them anyway. On the other hand you might want to connect a 
terminal to a PC (preferably an AT with lots of memory) so that 
two people can work on different tasks at the same time, time- 
sharing the microprocessor —- perhaps a solution when a computer 
intrudes upon a marriage. (You can also do this with a CP/M com- 
puter and the MP/M operating system, but be prepared for a slow- 
down. ) 

No other mail this month, so I have space to fulfill a 
promise I made a few months ago to explain how to use submit 
files for patching. You'll find submit files for lots of useful 
pat.ches on bulletin boards. The best application I've found is 
patching function key sequences into NewWord or WordStar 4.0 
(see previous column). You can do this with the WS/NW patcher or 
with DDT, but it's a tedious process of typing in well over a 
hundred two-digit hex numbers; if you make a mistake or if you 
change your mind about something, you have to do it all over. 
With a submit file all you have to do is make changes in the 
file, then repatch. 

SUBMIT.COM, which comes with CP/M, reads a file of commands 
and executes them just as if you had typed them in from the key- 
board at the A> prompt. XSUB.COM goes a step further, letting 
the contents of a file serve as input inside a program. It 
doesn't, unfortunately, work with WordStar or most. other common 
software. It does work with DDT. Here's how you would use these 
programs to enter function key sequences in NW. (As always, work 
with a copy of the program you want to patch.) 

You must have SUBMIT.COM, XSUB.COM and DDT.COM on your 
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working disk. Use your word processor in the non-document mode 
to create a "submit file." Each command or hex byte that you 
would ordinarily type in at. the keyboard goes on one line of the 
file, followed by a <RETURN>. My file for patching function keys 
starts like this: 


XSUB 

DDT B:NW.COM 
$0238 

03 

01 

40 

OD 

CEC. o6. 


The first line calls XSUB.COM into memory. The second loads and 
executes DDT. DDT will read the file NW.COM (which I'm assuming 
here is on the B drive) and display on the screen the hex num- 
bers representing its code. The third line of the file is a com- 
mand telling DDT to go to the starting address of the function 
key table (check your manual for the correct address in your 
version) and begin inserting new code. After that come the hex 
bytes to be inserted, one after another. At the very end of the 
file you put 


- [that's a period] 
GO [that's G-zero] 
SAVE xx B:NW.COM 


There's a <RETURN> after the last line. The period tells DDT 
you're through entering new code, and the GO exits to CP/M. The 
SAVE command writes the patched version of the program back to 
disk. The number shown as xx is very important. It's the number 
of 256-byte blocks the program will occupy on the disk; use too 
small a number and not all of the program will be saved; use too 
large a number and you'll waste disk space. To find the number, 
go to the A> prompt and type STAT B:NW.COM (or whatever program 
you're about to patch). STAT.COM must of course be on the disk. 
You'll see a display like this: 


Recs Bytes Ext = Acc 
54 8k 1 R/W B:NW.COM 


The number under "Recs" is the number of 128-byte blocks the 
program occupies; divide by two and you'll have the number to 
use in the SAVE command. Don't ask me why they use 256K blocks 
in one place and 128K blocks in another; I wasn't around when 
they wrote this stuff. 

The file of commands must have a name with the extension 
A> prompt and type 


SUBMIT KEYPATCH <cr> 


Then sit back and watch commands and numbers flow across your 
screen as if entered by an invisible typist. 
One caveat: there's a maximum size for a submit file. This 
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fact is very well hidden somewhere in the documentation; I re- 
member reading it once and haven't been able to find it since, 
so I don't know exactly what the limit is. I've found in prac- 
tice, though, that it's somewhere around 90 lines, which is 
enough for many common patches but not enough for a function key 
table. I broke mine into three parts, running them one after 
another. Each file has to begin by calling XSUB and DDT, then 
have an "S" command with a starting address right after the end 
of the previous patch. (My third file is the part of the table 
that goes in MORPAT, and begins with the address of that area.) 
Each file must end with the same SAVE command. 

When I made up my function key file I included the names of 
the keys and a description of the keystrokes I was patching into 
each one. When I was ready to patch I made a copy of this file 
and deleted all the descriptions. When making changes, it's much 
easier to figure out where you are in the annotated file. 


[Ahem. The earnest but absentminded production crew acci- 
dentally cut a couple of sentences from the last edition of 
"From the Mailbox." We abjectly apologize to Bill Steele and his 
readers. Luckily, however, the two sentences omitted were of an 
editorial nature not vital to the sense of the article. We've 
all been put on water and biscuits for two weeks and we'll never 
do it again.] 


A Perfect Filer Patch 


Kaypro users of the old Perfect Filer have run out of of 
time. The original PF had a maximum date of 1988. A patch to 
extend this to 1999 was published ina letter to Profiles 
back in October 1985, and I have had several calls from 
folks wanting the fix. It should probably be stuck in the 
next newsletter: 


1. Put your CP/M disk in the A: drive and your Perfect 
Filer disk in B: 

2. Type "DDT B:SETUP" 

3. At the dot prompt type "S0715" and hit return. 

4, DDT will display "58" (88 in hexadecimal). Type "63" 


and hit return. 
5. Type "." and hit return. 
6. Enter a Control-C to exit DDT. 
7. IMMEDIATELY type "SAVE 16 B:SETUP" and hit return. 


The Perfect Filer disk will now allow dates up to 1999 -- at 
which point you may have to buy a new computer! You can 
extend this to other Perfect Filer program disks by copying 
the SETUP file from your modified disk to the other Filer 
disk. The SETUP file lives on the program disk, not. the data 
disk, so you should only have to do this to your working 
program disk. Good luck. 

— Steve Willett 
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‘CUT AND TAPE TO YOUR COMPUTER 


Is It Worth Repairing? by Ron Jacobs 





What kind of computer do you have? If you have an old Morrow or 
Kaypro or other CP/M computer, you may be feeling as if you are 
missing out. on the cont.inuing computer revolution. Read this 
article, substituting your computer brand each time you read 
"Morrow." 

I noticed that. I have heard "Is it: worth repairing?" sev- 
eral times recently. I answer the phone and hear a sentence or 
two about what has gone wrong with a Morrow computer, and then 
I'm asked if the caller should repair it. The fact is that I 
don't. believe I can answer that. I might feel that we could dis- 
cuss it over a period of a few weeks and then I might feel con- 
fident in giving a recommendation. Consider the questions that 
go through my mind when I'm asked "Is it worth repairing?" 

1. What kind of person are you? That is, what would be your 
motivation for junking your Morrow equipment and getting some- 
thing else? Do you feel out of place with your old computer be- 
cause nobody to whom you mention the Morrow name recognizes it? 
Are you ashamed because you mention "CP/M" to software salesmen 
and repair shops and they encourage you to leave their premises? 
Do you want to have a new COmpULEE because it. is your style to 
buy what is new? 

2. Is your Morrow doing what you want it to do? For 
example, are you using it just for word processing (Wordstar or 
' New Word, etc.) and does it do that job adequately? Or do you 
want to do desk top publishing (if you do, you need a new com- 
puter). Maybe there is something that makes your Morrow incon- 
venient and you don't know that there is an easy solution. 
Another example: your associates have IBM clone computers. You 
want to be able to do word processing on your computer and have 
disks that you can exchange with your associates. You don't know 
that you could use DOSDISK to be able to read and change their 
disks in your Morrow and that they could then use those disks in 
their computers. 

3. Are you concerned that your Morrow is going to breakdown 
too frequently and/or cost too much to repair now that. it is 
older? How important is it. to you to have a reliable computer? 
Can you do without your computer while it is being repaired? 
Have you considered that a new computer may also have problems 
with the hardware or in getting the software set up for your 
needs? Do you want to learn the intricacies of a new computer? 
Is it worth while to you to get a spare Morrow? 

4. Have you developed a net:.work of friends and supporters 
through your use of and interest. in your current. computer? Do 
you want to change your relationship with that network or aban- 
don it? Since you are reading this article, you do have some 
friends in the Morrow community. Some Morrow users just don't 
have any support. 

5. Do you have an investment in customized software? Did 
somebody write a special program for you four years ago? Did you 
spend 18 months getting ZCPR running on your computer and are 
you having too much fun with it now to change? 


Everybody is unique. What is acceptable to me may not be 
acceptable to you. I can't easily answer the question, "Is it 
worth repairing?" You'll have to decide for yourself. 
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Tools for Tyros by Mike Allen 


301 North Roadrunner Parkway, #109, Las Cruces, NM 88001 
(505) 521-1567 . 


Here it is Friday the 13th and Sypko has been gently reminding 
me that the deadline is tomorrow. To be honest, there isn't much 
new in the CP/M world. Maybe I'll just let my mind (such as it 
is) wander. 

About the only thing I've seen new in the Public Domain 
world of software is another modem program called QTERM. It has 
some nice features such as the Kermit file transfer protocol, 
VT100 terminal emulation and split screen operation. However, it 
seems to have some bugs. I haven't been able to get the XModem 
or YModem protocols to work reliably. Both Jerry Maloney and I 
had it lock up for a while for no known reason. The documenta- 
tion seems to be pretty good but the patch instructions for 
matching your terminal and computer are sketchy at best and in 
some cases flat wrong. Some of the information is also missing. 
I've got it working (kind of) on my MD3 with the MDT-60 term- 
inal, but it needs some more work. 

I've been modeming to down-under (boy, Ma Bell loves me) 
with Ron Murray, the author of ZMP, and Lindsay Allen, a big 
Morrow fan. It seems a shame, but it looks like most. of the new 
CP/M work (exclusive of the Z world) is being done in Australia 
and Europe. We in the Morrow community are lucky to have a few 
active contributors like George Borys. We still see some neat 
new stuff, like George's SmartWatch, once in a while. 

I've been checking into the CP/M conference on GEnie 
(Wednesdays at 10 p.m. Eastern) to see if anything is happening. 
The only people I meet there are C128 users. I did get a chance 
to play with a C128 the other day and I'm beginning to see why 
CP/M isn't too popular among the C128ers. The biggest problem is 
their disk drives. They are awfully slow. And they don't hold 
much - about the same as a SSDD Morrow disk. CP/M is a pretty 
disk intensive operating system and the time spent waiting for 
that C128 disk drive would drive one nuts. Trying to use a pro- 
gram with overlays (like WordStar) would really be frustrating. 
Couple that with the fact that most C128ers only have one disk 
drive and you can see what kind of problems they're facing. For 
some reason Commodore decided not to distribute all the CP/M+ 
utilities, like SHOW. I hate to sound like a stuck record, but 
these C128 guys could use some help from the more experienced 
CP/Mers. There is an opportunity here. 

It looks like PC Pursuit was too good to last, at least in 
its present form. As of the lst of February the rates went up to 
$30/month and that is only good for 30 hours. After 30 hours 
it's $4.50 an hour. If you do a lot of modeming you can buy ad- 
ditional 30 hour blocks at $30 each. It's still a pretty good 
deal. 

A couple of people have expressed interest in hard drives 
and RAMDisks for their Morrows. There were two outfits making 
hard disk systems for the floppy Morrows: Advanced Concepts, 
8926 S.W. 17th St., Boca Raton, FL 33433 and WestWind Computer, 
33447 Western Avenue, Union City, CA 94587. I don't know if 
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either of these outfits are still supplying but I suspect that 
the Minni-Winnie from Advanced Concepts might be procurable. 
{[WestWind is not in the Morrow hard-disk business anymore. -Ed.] 

As far as RAMDisks go, the only one I know of is the SWP 
Co-Power-88 which also had an 8088 co-processor on the board. It. 
would run a very limited set of IBM software but the biggest use 
seemed to be as a RAMDisk. Again, I doubt if they are still 
available. 

I had toyed with the idea of making a Morrow RAMDisk and 
writing it up ala the MACK, but when the 256K DRAM chips tripled 
in price that project went on the far back burner. Maybe if they 
get back under $5 each I'll dig my notes back out. 

My first technological hobby was ham radio. As I mentioned 
in my last column, my dad has been licensed since 1939. I picked 
up my first license in 1955. Ham radio went through an inter- 
esting evolution. Before WWII it was all "build it yourself" and 
see what happens. Not all that many hams were electrical engi- 
neers and as a result they went and did things that weren't sup- 
posed to be possible because they didn't know any better. 

The years following WWII were the real boom years. Army 
surplus electronics could be had for a song. True, most of the 
stuff couldn't be used just as it was, but modifying the stuff 
to see what it could be made to do was exciting. I remember hit- 
ting "Surplus Row" in Chicago as a kid and being able to afford 
the stuff that was there. If you could get the license you could 
get on the air for fifteen or twenty bucks. That was a lot of 
allowance in those days but it was do-able. 

Then technology progressed. The stuff you could build your- 
self or get as surplus just wasn't adequate any more. You could 
still buy kits at a reasonable price from Heath and Allied but 
it was more than a few months allowance. Ma and Pa had to help 
out. But exciting things were still happening. I remember in the 
late 50s being one of the few on the air with Single Side Band. 
There weren't too many other SSBers to talk to but. those who 
were there (like Irv Hoff of IMP fame) were innovators. 

Things progressed even further and the cry was that the 
hobby was being taken over by "appliance operators" who just 
turned the knobs and talked. Some truth in that. Then the Jap- 
anese entered the market. In those days the exchange rate was 
¥360 to the dollar. Names like Kenwood, Yaesu and Icom replaced 
Collins, National and E. F. Johnson. Soon the American manufac- 
turers no longer could make money in the ham radio field. Of 
course, now with the exchange rate what it is, the Japanese 
equipment. is expensive. 

But what really drained ham radio was the advent of the 
home computer. Those bright teen-agers who would have been modi- 
fying an ARC5 surplus radio in the 50s were building an ELF from 
Popular Electronics or playing with a TRS80 Model I or a KIM-1. 
There was a newness that had gone from ham radio. While ham 
radio isn't dead (it's even growing some), it is a little mori- 
bund. 

Now what has this to do with computers? Well, maybe I'm 
imagining things but I think I see the same thing happening in 
the computer world. When I first started playing with computers, 
new PD software was flying left and right. You could hardly keep 
up with the latest revisions. The hobbiests were implementing 
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- compression schemes and inventing file transfer protocols. 
Build-it-yourself articles abounded in magazines like Byte and 
Dr. Dobbs' Journal. Ditto with programs. When was the last time 
you saw a program listing in Byte? Do you even read Byte? I 
don't and I still have a Volume 1, Number 1 gathering dust that 
was more interesting than any of the recent issues I've read. 

So where do we go from here? Does the average age of the 
computer hobbiest continue to climb 'til it reaches the late 40s 
like ham radio? Is the spirit of adventure gone? Most impor- 
tantly where are those bright, technologically minded teen-agers 
going? 

I'm not comforted by what I see. Someone tell me what the 
technological hobby of the future is. I want to get in on it. 


Hints and Kinks from the BBS 





The following excerpts are from the MOR and the BAMDUA BBS 
(Bulletin Board Systems) in Berkeley, CA. They are reprinted 
here because the three subjects dealt with are of particular 
interest and most of the readership doesn't have a modem, or 
live too far away from the BBSs to call in and follow the mes- 
sages. The first section is about ARK the latest way to com- 
press/decompress files; the second section is a treatise about 
the modem program MITE; the last one deals with CLOCKS for Mor- 
rows. -- Sypko Andreae. 


FILE CRUNCHING WITH ARK 


To: Ilbert Butler 
From: Mike Allen 


I agree with most of what you say. I was just trying to point 
out. that. there are pitfalls with ARK and that if it is used pre- 
cautions should be taken. 

I'm surprised that you've had "trashing" problems with 
NULU. The only time I've had problems in that way has been when 
the actions are taking place between two drives with different 
formats and then only in the case of different block sizes on 
the drives. Happens frequently when unsqueezing a file from an 
LBR on an HD to a floppy. I have found that the easiest way to 
avoid the problem is to cal] NULU from the drive you wish to be 
the destination drive and then open the file on another drive 
using the du: prefix. I NEVER change logged drives/users from 
within NULU since that seems to up the chances of scrambling a 
file. (I'm using NULU151 by the way). 

I'm afraid that I assume that everyone knows the idiosyn- 
cracies of relatively stable software and forget to pass on what 
I find. I do remember to pass on what. I find wrong in the newer 
stuff. I never mean to imply that the newer stuff is not as good 
as the older stuff. If I think it's worse I'll say sc! 


A os en ee 
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To: Mike Allen 
From: Ilbert Butler 


One thing about ARKs -- It is true that the CRUNCH algorithm is 
about 10% better at compression. But I appreciate it if, when 
ARKs are made, ALL the member files have their original names, 
and are also compressed using the ARK algorithm, i.e., com- 
pressed into the ARK by ARKx.COM, not previously crunched and 
then put in the ARK. The reason is that UNARC is available on 
most BBSs, and can type a DOC, FOR, or ASM file to screen 
online, but only if it is made a member of the ARK by the first 
method. When made by the second method, there is no opportunity 
to preview. You have to download and extract it to find out what 
it says. 


TIPS AND TRAPS WITH MITE 


To: All MITE Users 
From: Ilbert Butler 


Mycroft Labs, publishers of MITE, is out of business, and there 
is no referral number. Any help you get from now on will be from 
users. Here are three tips: 

1) MITE Demands an Exact Modem Cable & Exact Modem Dip 
Switch Settings. The MITE manual declares only one specific null 
modem cable to be correct. for all Morrow MDs. This cable swaps 
pins 2-3, 4-5, and 7 is straight through. But instead of swap- 
ping 6-20, MITE wants you to connect. Morrow pin 6 to modem pin 
20, BUT modem pin 8 to Morrow pin 20. 

Why is this? The Intel 8251A USART serial controller on 
MD-2s & -3s has no carrier detect input on the chip, and there 
is no carrier detect input pin in the factory default serial 
port configuration, since this is a physical impossibility. MD-. 
HD factory default serial ports are compatibly configured, even 
though the Zilog Z80 SIO/9 serial controller does have a carrier 
detect input. SO, for ALL MDs, MITE does a custom I/O routine 
that interprets an incoming signal on Morrow pin 20 NOT as data 
set ready (which only means the modem is turned on & working), 
BUT INSTEAD as carrier detect (which means the modem is receiv- 
ing a carrier from a remote modem). 

Under this custom I/O, MITE also determines that, if there 
is a carrier detect signal, you cannot dial a call, because you 
are already connected. 

This means that to run MITE, you must use their cable pin- 
out, and you must not force carrier detect on with a dipswitch 
at the modem. Or else you must dial all calls manually. 

Likewise, since a modem hangs up when the computer drops 
either request to send or data terminal ready, or both, you can- 
not hang up the phone, unless these lines are not forced by dip 
Switches at the modem, and you use the MITE cable pinout. 

The dip switch settings demanded by MITE (no handshake sig- 
nals forced) are the opposite of what most modem manuals rec- 
ommend (all handshake signals forced). The modem manuals tell 
you to force lines, so you will be able to communicate with only 
pins 2, 3 & 7, with no hardware handshake at all, and perhaps no 
software other than homemade BASIC program routines. MITE only 
a eee 
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hardware handshakes with the modem. It does not use Xon/Xoff as 
a serial protocol, even though it sends ~S & “Q to a remote 
modem in communication. This is all poorly documented in the 
manual. 

2) MITE 2.7 Does Not Recognize 1K Block Transfers.—Don't 
Know About Later Versions. This program preceded 1K block trans- 
fers, and the code requesting them confuses the program. You 
’ have to suppress the 1K request at the remote BBS end with the 
appropriate KMD command. From the prompt in the file transfer 
area, type: KMD<cr> for a menu of KMD commands. 

3) Although the Modem Code Is All Inside MITE, and the Com- 
puter Code Is All Inside the Installation Overlay, the Overlay 
Must Have the Right Name To Install a Specific Modem. 

What does this mean? It means that if the only overlay you 
have for an MD-3 is named CTSMCD.HEX, it won't install for a 
Hayes modem, until you rename it MICROD.HEX. You don't have to 
change it or reassemble an ASM file. You just have to rename it. 
Once renamed, it won't install for a CTS modem. Likewise, if you 
have CTSMD2A.HEX for an MD-2, it won't install for a Hayes modem 
until you rename it MICROD.HEX, and once renamed it won't in- 
stall for a CTS modem. Likewise, if you have CTSM11.HEX for an 
MD-HD, it won't install for a Hayes modem until you rename it 
MORROW11.HEX, and once renamed won't install for a CTS modem. 

In case you are wondering what MITE did, they made all pro- 
grams sold specific to one make & model of computer and modem, 
and didn't publish the instructions. You had to be a registered 
user and call them to know how to change modems. Cheap trick. 
Thanks to George Borys for figuring it out. 

Mycroft Labs deserved to go out of business. 


Corresponaence For Kaypro-related articles, adver- 
a tisements, or memberships in BAKUP ($20/ 
Quer ies yr), write to P.O. Box 8537, Berkeley, 
a CA 94707-8537; or call Bop Athey at 415- 


Conplaints 526-3541. 

] For Morrow-related articles, ads, or 
tuitorial wemberships ($20/yr) in BAMDUA, write 
Submissions to P.O. Box 5152, Berkeley, CA 94705, or 

1. butler at 415-526-8655. 
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Mor's Corner by Sypko Andreae 
a 


MOR, P.O. Box 5487, Berkeley, CA 94705; (415) 658-0152 








Helpful Utilities? 


This time I'm going to tell you something about my adventures 
(mis-adventures?) with several public domain utilities in the 
process of trying to clean up my hard disks. You'll hear about 
BU20, FIRE12, SAPP20, ZAP35, and DU89. They are all available on 
the MOR BBS, which will absorb the BAMDUA BBS as of the February 
1, 1989. 

My MD222 is a converted MD11 with two 22 MB hard-disks and 
one floppy. I use it every day for modem communication, book- 
keeping, letters and other writing, database work, etc. Apart 
from frequent incremental back-ups, every half year I empty each 
disk out on some 30 floppies, reformat the hard-disk and reload 
all the files again, using BU20 to back the files up, and NSweep 
to restore them. Why do I do this? When you use a disk a lot 
(erasing files, creating new ones) the files will become "frag- 
mented" and we say then that. the disk has become "scattered." 
After a while that really slows things down. In addition I 
simply believe that it is a good idea to reformat. my hard-disks 
at least once a year. 

To take care of a fragmented disk this is what you have to 
do: First, back up the entire hard-disk. I use BU20 for full 
back-ups, and again BU20 for incremental back-ups thereafter. 
During a full back-up you copy all the files (BU20 command: BU20 
AB -A). Every file that. is backed up will get its Archive file 
attribute set. During an incremental back-up only files that do 
not have the Archive attribute set are copied: Only those files 
are backed up on floppy that have been changed or which were 
created since the last full back-up. Saves a lot of time. 


Re-organizing Your Disk 


You can use SAPP20 and FIRE12 to re-organize your disk. But read 
this article first and then decide if you really want to do 
this. If you're still game, this is what you do: After the full 
back-up, run SAPP20. SAPP Sorts And Packs the disk directory. 
You have to do this before you run FIRE12, the File Restore pro- 
gram. FIRE12 picks up all the scattered file pieces, then re- 
writes each file in one contiguous piece. Thus all files in all 
, user areas of the current disk are treated. A disk reorganized 
in this fashion makes your programs run much faster, at least. 
the ones that use large files (especially database programs). It 
also makes it less likely that the system will pick up a wrong 
piece of file. This has actually happened to me a few times. 
Very disconcerting! 

Now let's step back a moment to explore how files are 
stored on disk in more detail. By way of introduction I'll let 
Steve Dirickson, sysop of Seattle's "Downspout" BBS, explain it 
to you because he does it so nicely: 


"Compatible operating systems store files on disk in what 
ee 
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are called "allocation groups." The size of an allocation group 
is determined by the system's BIOS, and is typically 1K or 2K 
bytes for floppy disks, and 2K, 4K, or 8K for hard disks. The 
allocation group (4K for MD11) is the smallest unit of storage 
on the disk; if you write a one-byte file to the disk, it will 
take up just as much space (in the sense of making that space 
unavailable for storing other files) as would a file the size of 
one entire allocation group. 

"When a disk is formatted, all allocation groups are free, 
and the first file written to the disk occupies the allocation 
groups immediately after the directory, in sequence. The next 
file written to the disk occupies the groups after the first, 
and so on. When a file is deleted, its allocation groups are 
freed up, and may be reused by the system. 

"As files are written and erased, later files start to be- 
come "fragmented"; i.e., they are written with some allocation 
groups in one location and other groups in other locations. 
Thus, when these "fragmented" files are read or written, the 
system must position the read/write head over one track for part 
of the file, then move the head to another track for more of the 
file. This starts to degrade disk performance, because more and 
more time is spent moving the head around to find the various 
parts of the file, causing access times for the files to get 
longer and longer. This problem affects both floppy and hard 
disks. The effect this has on the system response is dependent 
on how the system buffers the disk data in memory. A system that 
uses a "track buffer" system, where an entire track is saved in. 
memory each time the disk is read, will be VERY much slower when 
accessing severely fragmented files than when the files are 
stored in sequential allocation groups, and thus several related 
Groups are kept in memory together. 

"The only way to recover from this situation has been to 
copy all files on the disk to back-up disks, reformat the disk 
(or simply erase all the files), and then recopy the files from 
the back-up disk(s) to the working disk. This takes a signifi- 
cant amount of time to do, and it is even more inconvenient if 
files are assigned to several user areas on the disk, since each 
user area on the back-up disk must be individually entered and 
the files in that area copied to the corresponding area on the 
work disk. 

"FIRE12 (RESTORE) is designed to make this process easier 
by eliminating the copy to and from the back-up disks. RESTORE 
works only on the disk being restored, and thus may be used even 
in a single-disk system." 


Thank you, Steve. By the way, this copying from hard-disk 
to floppies has been made much easier with NSweep. Still easier 
is using BU20, my back-up program of choice. It does a file 
oriented back-up just as you would do with NSweep, only automat— 
ically. It only asks you to feed it floppies. All hard-disk user 
areas are faithfully recorded in the corresponding user areas of 
the floppies. 


First a Full Backup 


Sounds good so far, doesn't it? But there are some pit- 
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falls. Let me tell] you what happened to me. First I backed up my 
C: hard-disk. I figured that if something went wrong I could 
still run from the A: hard-disk. Sure enough, I was in for some 
surprises. : 

After I opened up the FIRE.LBR (I used LT27, real slick) 
there was no SAPP20.COM file among the SAPP files. I tried to 
assemble and link the SAPP20.Z80 source file, but the LINKer 
would not do the job right. Finally I gave up on the assembly 
and found SAP20.ARK on Werners's CO-ED BBS and this time there 
was a SAPP20.COM file within. I read the SAP20.DOC file care- 
fully, then patched SAPP20.COM as I was told. That is how I 
found the first bug in the documentation. 

I used ZAP35 to patch and noticed the byte values did not 
match the documentation. The documentation was one byte off, 
probably because the sign-on message at the beginning of the 
file had been changed from "SAPP Version 2.0" to "SAPP Version 
20", which caused all the bytes to move over one place. So where 
it says "Byte 0124h should be 00 for Morrows," make that "Byte 
6123h should be 00 for Morrows" and you will be okay. Yes, you 
have to pay attention all the time. 

Next I patched one byte in FIRE12.COM to make the report it 
produces scroll rather than overwrite. This allows you to print 
the whole FIRE report by hitting CTRL/P before you start FIRE. 
In FIRE12 the bytes were in their promised spots as my very 
suspicious checking revealed. Can't believe that documentation! 

In the FIRE.LBR there is also a program DMAP.COM which 
shows you how bad your files are fragmented. Do not run DMAP.COM 
under CP/M+ (hard-disk Morrows): it will destroy your directory 
in one swift sweep. I know, I tried it. But I was ready for it. 
Risking everything to write an educational article... 

Both SAPP and FIRE have limitations in the number of direc- 
tory entries they can handle. In my machine SAPP could handle 
1871, and FIRE could handle 1536 directory entries. How do you 


know how many directory entries you have used? Run SHOW, a CP/M+ 
utility: 


C> SHOW [DRIVE] 
C> SHOW [DIR] 


The first call displays 10 lines of interesting data about 
your particular hard-disk among which you'll find the maximum 
number of directory entries: 2048 for Morrow hard-disk machines. 
The second call tells you how many directory entries are still 
free. I had 1050 free, which means that I had 2048-1050 = 998 
directory entries used. Because 998 is less than what SAPP 
(1871) and FIRE (1536) can handle I had nothing to worry about. 
Onward! 

To check on how well SAPP would do its job, I peeked first 
at the directory with ZAP35: After bringing it up, ask for S(ec- 
tor); you wind up at Track=0008, Sector=0000, Block=0000 which 
is right at the beginning of the directory. The directory uses 
tracks 8 through half-way 15 (O00F hex). ZAP is peculiar in that. 
it. can only look at the first 8 MB on the disk; I wish someone 
would fix that. In addition I have not yet found a way to print 
sectors with ZAP, so after browsing around in the directory for 
a while I used DU89 to print the first 20 sectors of the direc- 
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tory on paper. By the way, DU89 can "see" as far as 13 MB into 
the disk. 

Then I took a deep breath and ran SAPP20. It said: "Read, 
Sort, Write, Done,” and was done in about 30 seconds. With ZAP I 
took a peek at the directory tracks again and indeed! The direc- 
tory was neatly sorted, first by user area, then by filename. 
Then I looked at the whole disk with NSweep. Fantastic! Then I 
ran the directory utility SD: 


C> SD SANS [means: Show me the whole disk] 


Everything looked really pretty until I discovered an eerie 
looking file, the last entry in C15. It was of monstrous size: 


C15:eeeeeeee.cee 6456 k 


As huge as SD wanted me to believe it was, it did not take 
any real space on the disk. That means trouble! A bug in SAPP? 
Or an undocumented feature perhaps? Strange as this was, I 
figured FIRE wouldn't mind this file since, after all, it was in 
its properly sorted place in the directory. I decided to leave 
the file alone and ran FIRE: 


C> FIRE12 


FIRE asks you to be sure you have less than 1536 directory 
entries and invites you to respond with "Y" if that is the case. 
If not: Directory Death! Next, it takes its time calculating. Be 
patient; in my case it calculated for 7 minutes. Then it starts 
moving the files around, picks up all the little pieces, re- 
writes them in clean, long, contiguous files. This process is 
quite slow, something like half a minute per file, depending on 
the length of the file and where it is. My 998 directory entries 
representing 837 files took 7.5 hours to be rewritten. So I 
started FIRE just before I went to bed. When I woke up in the 
morning FIRE was still working away. I watched it finish while 
having breakfast. 

Looking at the result with ZAP I was at first impressed. 
Beautiful! To really enjoy it I ran SD SANS. What was that? A 
closer look revealed that the mysterious eeeeeeee.cee file now 
resided in C0:. NSweep could not see it, but SD could, showing 
its enormous (fake) size. 


Eeeeerie Files Appear 


I was curious to see what SAPP would do with this eeeerie 
looking file, so I decided to run SAPP and FIRE again (what. the 
hell, I have a back-up!). SAPP didn't have much to do this time 
and, maybe out of boredom, created another strange (and seem- 
ingly huge) file, calling it eDU89LOG. I remembered I had re- 
cently deleted a file called DU89LOG. Here it was again, 
Slightly renamed. Why would SAPP resurrect deleted files? 

Brashly I went ahead anyway and gave FIRE. But FIRE would 
not run, complaining that the directory had not been properly 
sort.ed. What about that., SAPP? I ran SAPP again. FIRE quit once 
more protesting about an unsorted directory. Then I ran SAPP one | 
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more time. FIRE didn't accept. Back to SD again. Now there were 
four mysterious huge files with strange names: eDU89L0G had be- 
come eeDU891L0.G, a few more deleted files had reappeared 
(slightly renamed), and eeeeeeee.eee was there as huge as be- 
fore, but now in C10. 

An inspection with ZAP showed the eeeeeeee.eee file to be a 
directory entry nearly entirely consisting of E5 bytes. E5 bytes 
mean "free, unused space"; it was not a real file at all, it 
only looked like one. However, SAPP must not. have been able to 
see the filenames with "e" in them and thus was unable to sort 
all these eeerie files to the end ("e" should have sorted after 
"Z"). FIRE wasS correct to complain about an unsorted directory. 
Conclusion: SAPP doesn't do a very complete job. 

I felt compelled to go in manually with ZAP and I searched 
for any E5 byte in the directory space, which ZAP35 does very 
well. I found the four "e" files quickly and renamed them 
22222222.001, etc., while placing them in area C15. Now SAPP was 
forced to sort them properly; positioned at the end I didn't 
think FIRE would be bothered by the ghost files. At bedtime I 
started FIRE again. It calculated for 7 minutes, gave a report 
of its plan of action. All looked fine; FIRE went about its 7 
hour file-moving chore. 

The next morning FIRE finished and I looked at the results 
with ZAP and SD. All was fine. Or was it? Something made me look 
inside the 22222222 files. To my horror they had bits and pieces 
of real files inside them! I was able to recognize those bits 
and pieces as belonging to my PCFILE report files. What would 
have happened to those files? A quick look: Sure enough, they 
were corrupted! But I didn't break out in a cold sweat yet: I 
had made a back-up! Onward! 

The corrupted PCFILE report files in turn had pieces of my 
bookkeeping SupeCalc files in it. That was not right either! 
After a little sleuthing I found out which .CAL files they were 
and ran SC2 on them: They were fine! Inside one of the 22222222 
files I had found pieces of a particular .CAL file that was no- 
where to be found. Then I realized that that .CAL file had been 
safely archived away and deleted from the hard-disk last year; I 
had forgotten about it. 

What if these ghost files only ate deleted files? Carion 
eaters! But. if they ate other, healthy files as well, how would 
I ever find out. which files they were? I made a quick survey of 
my most precious files and projects, and could not find anything 
wrong. Of course I only checked a small part of those 837 files. 
Who knows what other damage I'll find months from now? I may 
never know, but at least I have a back-up. 


Not for the Faint of Heart 


Here I am, using my MD222 after a rigorous cleanup, with 
only six files devastated. Was it worth it? Well, I learned a 
lot and got a nice "war-story" article out of it. But, I'm 
sorry, I can't honestly recommend a SAPP/FIRE procedure to any- 
one anymore. I am going back to full back-up, reformat, and 
restore every half year or so, with numerous incremental back- 
ups in between. 

George F. Reding was the last author/modifier of SAPP and 
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FIRE, dateline August 2, 1987. Where are you George? I want to 
talk to you. Public domain software, I should have known. In the 
documentation of FIRE it talks about all the terrible bugs of 
the past and how they were fixed. George Reding proudly pro- 
nounced that FIRE had passed extensive testing on his converted 
MD11: another MD222! But he did not test on a disk with a half- 
year load of actively used and fragmented real-life files. Maybe 
he missed sonething. RESTORE is the forerunner of F1RE; this is 
what it says in the RESTORE documentation, and it applies to 
FIRE equally well: 


"x X*kWARN ING*** 


Since RESTORE does in-place restoration of the disk, it has 
simply INCREDIBLE potential for wreaking havoc with your disk if 
something goes wrong while it is working, like a loss of power 
or a controller fault. Therefore, you should ALWAYS back up the 
disk to be RESTOREd shortly before running the program. This 
shouldn't be much of a problem, since you do a full back up of 
your hard disk at least every weekend, right? RIGHT? NO?!! Well, 
if you don't, you should. It only takes one occurrence of having 
to rebuild a disk's directory one group at a time to make youa 
believer. Just after a full back-up is the optimum time to run 
RESTORE. 


DISCLAIMER: 


This is a very useful utility, and I have tested it extensively. 
However, as noted above, it is also very capable of lunching 
your disks completely if the system has a problem. Use it in 
good health and happiness, but MAKE BACKUPS BEFORE YOU USE IT!! 
Papa Wallenda ran his system without a back-up. He's not around 
any more. 'Nuff said. (Steve Dirickson, Aug 1987.)" 


I repeat: It has simply INCREDIBLE potential for wreaking 
havoc with your disk. No kidding! But if you have to make a full 
back-up anyway, then why go through al] the SAPP/FIRE trouble? 
BU20 does a good back-up job which is easily restored with 
NSweep. If you reformat in between, all files will be contiguous 
and nearly alphabetically sorted as well. What more do you want.? 
And whatever George Reding may have tried, FIRE is so slow that 
a BU20/NSweep procedure looks fast by comparison! I guess at 
this point you can draw your own conclusions. In any case, think 
twice before you play with: 


aetet PITRE that 
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VOLUNTEERS WHO ANSWER HELP CALLS OF MEMBERS 


PERSON TO CALL IF YOUR PRIMARY 
CP/M EXPERIENCE IS WITH KAYPRO 


PERSON TO CALL IF YOUR PRIMARY 
CP/M EXPERIENCE IS WITH MORROW 


re: Beginners & General 


Athey - Folsom (peginners SIG) 
Van Sickle 


Campbell - Charnes - Korte 
Oechs li 


re: CP/M, MS-DOS & Other Operating Systems 


Fowler - Pugh - ae Castro 
Winyara ~- McPneeters (hardware) 


Borys (haruware) - butler (Mac) 
Campbell(Mac & Atari) - Korte 


re: Other User Groups, Newsletter 


Athey - Winyaru 


Butler (legal) 


re: WordStar & NewWord Word Processing 


Athey - Buck - Peeples 


re: Database Programs 


Pugh (GBASE) - Cole (Pearl) 


Butler - Campbell - Charnes 
Naparst. - Oechsli 


Campbell (dLASL) Gowens (Pear 1) 


re: Perfect Writer / Calc / Filer 


Bruner ~- de Castro - van Oosten 


Athey (Calc) - Willett (Filer) 


(not conmon among Morrow) 


re: Programming Languages 


Bruner (MBas ic) 


Winyara (Pascal) 


borys(Mbasic) Mckusick (Pascal) 


re: ZCPR3 Systems & MEX Modem Program 


Charnes - Fowler 


Charnes - Korte 


re: Other Programs by Name or Type 


Lautenberger (spreadsheets) 


Becker (Handyman) Bruner (Xtrakey) 


Uzzell (Framework) 


Charnes (BackGrounder) 


Johnson(Quest & spreadsheets) 


415 AREA CODE PHONE NUMBERS & RULES FOR ALL CALLERS 


PRIMARY CP/M EXPERIENCE KAYPKO 


Bob Athey BBS or 526-3541 
Dennis BecKxer 625-3865 
Bob Bruner BBS or 528-1065 
John Buck 268-9541 
Ted de Castro 581-88&z 
Leonard Cole 527-2110 
Anne Folsom 643-5168 
Ken Fowler 222-0830 
Walt Lautenberger 285-2266 
woody McPheeters 38BS 548-3126 
Chris Peeples til 11 055-4438 
Steve Puch SZIH 1242 
David Uzzell - 465-3013 
Jeanne van Oosten 547-4792 
Georye Van Sickle 682-3188 


PRIMARY CP/M EXPERIENCE MORROW 
Georye borys til 11 582-7615 
Tlbert. butler til 11 526-655 
Peter Campbell 527-3307 
Rick Charnes 6S or &26-944% 
Bruce Gowens 268-9450/545-8Uu2 
Wesley Johnson til 9 444-U5b66 
Gene korte 525-5944 


Lee McKusickx aim only %49-9053 


525-ZUb6 
527-6U89 


Stan Naparst 
Frank Oechsli 


RULES FOR ALL CALLERS: 

Time: Unless noted, weexauys 
7-10 pin, weekends 10am-1Upm 
Long Distance & Toll Calls: 
keturred COLLECT 

No Criticising Unpaid Help! 
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BAMDUA-LAKUP News 


ZENITH 171 
PORTABLE 


COMPLETE 
IBM-PC Com- 
patibility! 

With: Super Twist 
Screen, 

RAM, Dual 5-1/4" Disk Drives, MS- 








DOS 2.11 and Battery $1,195 
Options: 1200 Modem $195 
Ext’l Video $185 
10Mb Hard Disk $795 
360K add’1 RAM Disk $149 
ZENITH 183 
PORTABLE 
Dual Specs: 
Super Twist 
Screen, 640K 
RAM, 20 MB 
Hard Disk & 3- 
1/2" Floppy $2,195 
Options: Portable printer! $145 


PC file xfr software with 
cable $95 


Carry Case $60 


BLUECHIP i8m Compatible 


Includes: 640K RAM; Mono 

Monitor; DOS; 2 Serial 2 Parallel, 

Clk/Cal, and 30 Meg Hard Disk ’$995 
AST Premium 286 6, 8, 10 Mhz; 
No wait state. PC Magazine Editor's 
Choice 


Includes: 1.2Meg/360K Floppy; 512K 
RAM; Cik/Cal; Mono-Graphics Mon 
& DOS, and 20Mb Hard Disk $1,995 


CORDATA AT IBM Compatible 8 


Includes: 360K Floppy; 640K RAM; 
Clk/Cal; Mono-Graphics Mon; DOs; 
Tutor and 20Mb Hard Disk $1,495 


ZENITH Z-158 
IBM Compatible 
Dual Speed 

Includes: Flo 

_ Drive; 640K BM: 
Mono-Graphics Monitor; DOS; and 
20Mb Hard Disk $1,195 





DOT MATRIX PRINTERS 
Epson FX 85 $275 
OKI Cut Sheet Feeder $150 


HEAVY DUTY LETTER 
QUALITY PRINTERS 


DTC/Olivetti: 45 cps with dual bin cut 
sheet feeder & tractor $895 


Primage 90: 52 cps with single bin cut 
sheet feeder & tractor $895 


LASER PRINTERS 


Okidata Laser Line 6: LaserJet Plus 
compatible with 15 fonts $1,695 


NEC 890 (Postscript & LaserJet Com- 
pee) with 35 typefaces & 3Mb 


CABLE/SWITCH 
Parallel Switch $89 
Serial Switch $79 


Parallel Cable for Morrow or IBM $16 
For Morrow Printers: 


Tractors $135 

Multi-Strike Ribbons $7 

Print Wheels $18 
MODEMS 

1200 Modem $289 

Volksmodem-300 $20 


Hayes Compatible - 1200 Internal $99 


SOFTWARE & MANUALS 
Supercalc II for MorrowCP/M $185 
Turbo Pascal Ver. 4.0 (IBM) $55 
Reachout Upgrade for MM 300 $10 
Perfect Software for MS/DOS $50 
SuperCalc 4 for MS/DOS $179 
Ventura Desktop Publisher $450 
Morrow Software Manuals (each) $5 


SCANNER & FAX (1BM Comp.) 


Datacony 730 Scanner with ae ie 





& Publishers Paintbrush 

Datacopy Microfax (internal FAX 

board with 1200 Baud Modem) $795 
LOCAL AREA NETWORK 

Adevco/Morrow Kit (List $350) 

For MD-3/3P/5/11/16/32 $90 

———. 
~—= WORLD 
—= BUSINESS 
12186 Winton Way 
Los Altos, CA 94022-6431 


(415) 941-3269 or (415) 941-1979 





$3,495. ~ 





SOL¥6 WO ‘AgTISWUa 
L8¥S XOH °O°d 
MATARY SYANMO MOUYOR 





